ervinutzfandomcom-20200214-history
A cheat guide
HOORAH! ---- Administrators, commonly known as admins and also called sysops (system operators), are regular editors who have been entrusted access to a number of restricted technical and maintenance features ("tools"). Note that administrators as a rule see exactly the same IP information about users, that other (non-administrator) users see, and can neither view pages deleted using oversight, nor modify other users' bot or sysop status. Bureaucrats can add or revoke sysop status, or remove all permissions. __TOC__ Protecting pages Administrators are able to protect a page to restrict editing or moving of that page, and remove such protection. Protection can be indefinite, or expire after a specified time. *Full protection prevents editing by everyone except administrators. Fully protected media files cannot be overwritten by new uploads. *Semi-protection prevents editing by unregistered contributions and contributors with accounts which are not autoconfirmed. *Move protection protects the page solely from moves. *Upload protection protects the file from reupload, does not protect the file page from editing. Changes to a protected page should be proposed on the corresponding talk page, and carried out if they are uncontroversial or if there is consensus for them. Administrators may unprotect a page if the reason for its protection no longer applies, a reasonable period has elapsed, and there is no consensus that continued protection is necessary. Contacting the administrator who originally protected the page is advised in unclear circumstances. A log of protections and unprotections is available at . An exercise to test protection can be found at Test Wiki:Admin School/Protection. Rollback On Wikipedia, this tool is avaliable to Administrators, and they can grant it to conventional users who are trusted with it. On this site however, this tool is made avaliable for everyone. All of your time as an admin may be spent reverting changes made to an article page. You may be used to the undo feature where you can undo the last edit to the article. As an admin, you additionally have a rollback feature to expedite the process. Where the undo feature lets you undo one edit, the rollback feature lets you undo all the consecutive edits made by an editor. This is handy, for example, if an IP posts eight edits to an article and you want to revert all eight edits. Simply hit rollback and all eight edits will be undone. Conventionally, administrative rollback is only used to revert simple vandalism or large amounts of mistaken edits. Using rollback to revert conventional good-faith edits is frowned upon because it leaves no useful message to the editor you are reverting and implies you thought their edit worth nothing more than the treatment of a vandal. A page to test this function can be found at Test Wiki:Admin School/Rollback Deleting pages # Go to the article you wish to delete. # Above the article, you will see tabs, in between history and move you will see Delete - click this button. # Next to reason for deletion, type the reason the page is to be deleted into the box, this should refer to a particular discussion page, or a particular criteria for speedy deletion such as hatred, etc. You should use an informative reason: "Vandalism" is not helpful, "Speedy deletion per Vandalism- Hatred slurrs, blatant remarks." is much better. If text from the article already appears in the "reason for deletion" box, please review that text to remove any libelous, attacking, or other personal information which may appear there; otherwise that material will appear in the deletion log, where it is very difficult to remove. # Click the button Delete this page. # All revisions of the page will then be deleted. # Many pre-loaded deletion rationales can be found using the drop down option. Deleting a revision Under certain circumstances, such as edits involving libel or a user's private information, a particular revision may need to be deleted from history. To do so, delete the page, and selectively tick which revisions you want restoring (you may find it easier to select all the boxes by clicking "invert selection" first, and unclick the bad revisions). Deleted revisions will only be visible to admins. # Go to the article you wish to restore. # Just below the title, you will see "View or restore (one) deleted edit?" - Click on (one) deleted edit. # This will list all the deleted revisions of the article. Next to each revision you will check boxes. If you are wanting to restore all the revisions, leave all the boxes unchecked. # Towards the middle of the screen, there is a box with comment next to it. Type the reason you wish to restore the article. # Click on restore. # The page will then be restored. Restoring selected revisions # Go to the article Wikipedia:New admin school/Deleting/delete. # Insert an edit in which you will want to avoid restoring after you delete the page. # Repeat steps 2-4 of Deleting a page. # Repeat steps 1-4 of Restoring a page. # In order to restore selected revisions and not restore the edit that needs to be removed from the page history, select the checkboxes only of the edits you need to restore (note: by holding the shift key on your keyboard and selecting one checkbox and the checkboxes above or below it, you can select multiple checkboxes without having to click on each one by one.) # Repeat steps 5-6 of Restoring a page and the revisions you selected from the checkboxes will be restored. Dealing with disputes ;Tips Advice from other admins who have been on the front lines *When wading into a dispute, stay excruciatingly civil. Many in the dispute will be looking to you as an authority figure, so it is essential that you set an excellent example of behavior. *In general, never issue a block unless you have first tried warnings at both the infringing editor's user talkpage, as well as the location of where the attacks are taking place. *When issuing a warning to the article talkpage, don't single out individual editors. Make a general appeal for calm, link the appropriate policies, and be very ambivalent about who exactly you are referring to (even if it's obvious). Referring to all editors equally can help calm the situation. *Try to avoid using the word "you" in your posts. Referring to everything in the third person can help reduce tension. Referring to everything in the first person plural ("we"), can reduce tension even more, if you're careful not to presume too much. *Most disputes cannot be adequately resolved until the editors are civil to one another, so that's a good place to start. However, be aware that just because someone is uncivil, does not mean they are wrong about the article. There may be a gang or tag team situation. *Be even-handed about issuing warnings. If you warn one editor, but not others who have been equally as disruptive, this can exacerbate problems. However, you don't need to use the same wording with all editors. With two editors in a dispute, one that has a history of disputes might warrant a strong warning such as, "You've been warned about this before, please cease this or you could be looking at another block," while the other editor might warrant, "This isn't like you at all. Try to scale things back a notch?" *Look for places where the whole framing of the issue is polarizing the dispute. Some issues can be rectified simply by a minor change to a title or section structure *If the participants attack you, don't take it personally. There are complex psychological factors at play in a dispute, especially towards a mediator or perceived authority figure. Anger from the participants may have nothing to do with anything that you actually did, so don't react defensively, just take it in stride, and keep your eye on the goal: High quality articles. If you feel yourself getting angry, let the article sit for awhile, and go work on something else. *Disputes generally don't need hour-by-hour guidance -- checking in every day or two may be all that's needed. *Sometimes it is helpful to ask one side to describe what they think are the best or most reasonable points by the other side. *Remember that your goal is not to shoo people away from a disputed article, but to help restore the article to a state of "healthy" editing, where editors flow through, adding to and improving the article in a steady stream of constructive changes. *Be wary of "admin shopping". Sometimes if you take action against an account, they will immediately accuse you of being partisan and challenge your "uninvolved" status. They may do this because they have had success in the past with this kind of tactic, and intimidating all admins away from them, or at least intimidating away any admins who don't agree with them. If you are sure of your neutral status though, don't be afraid to stand your ground. Getting a second opinion from another admin can also be an effective defense against this. Things to avoid *Don't lose your cool. If you attempt to resolve thorny disputes, you will be the target of baiting, incivility, and potentially personal attacks. Some editors are understandably angry at "being told what to do"; others may believe that if they draw you into a personal argument you will be "involved" and unable to neutrally intervene. Don't take the bait. Responding in kind is never helpful, and one of your roles is to model appropriate behavior. You are never compelled to respond to insults or incivility. If you find yourself getting angry, go work on something else for awhile. *Don't issue blocks without warning. It is extremely rare that a problem is so urgent, that a user needs to be blocked without "a warning shot across the bow." Most people, if they know a block is imminent, will voluntarily moderate their own behavior. And even if an editor is doing things in a rapid-fire manner, such as changing templates or moving articles, a quick talkpage message, "Hey, hold up!" may be just as effective as a block, as it will post the "new message" banner to the editor. Never use blocks as punishment, use them as a last resort. The best way to offer a warning is to politely explain the problematic behavior, to clearly state what may happen if they do not change, and further, for you to explain how they can contribute better if they do change their behavior. Where possible, try to end on a positive note. *Don't issue blocks unevenly. If two people have been yelling at each other and you only block one, the other one should probably at least get a warning at their talkpage. On the other hand, don't feel compelled to block multiple editors when only one is acting problematically; treating apples and oranges identically is uneven as well. *Don't lose your neutrality. Do everything possible to avoid any perception that you are agreeing with one side or the other. Because as soon as you do, the other side may stop listening to you. Don't give up their perception of your neutrality -- it's a precious thing, that once lost, is near impossible to regain. *Avoid issuing opinions on content, except in blatant cases. Stick to the user conduct. As soon as you become involved in the content wars, you become more of a participant. If you do feel it necessary to issue an opinion on content, keep it very very well-grounded in policy and consensus. Link policies, give diffs to proof of consensus. Portray yourself as a judge of existing consensus, not as someone who is enforcing your own opinion over everyone else's. *Don't pounce on new editors. Be careful about censuring a new editor who wanders into the dispute unaware. Even if an article is under strict restrictions, always give the new editor the benefit of the doubt. Always Assume Good Faith, and Never Bite the newbies. *Don't encourage admin-dependency. Do not foster any sense that administrator intervention is "needed" in disputes. Where at all possible, editors are supposed to deal with their own disagreements. Blocking IP address blocks In addition to the advice below, there are special considerations to take into account when blocking IP addresses. IP address blocks can affect many users, and IPs can change. Users intending to block an IP address should at a minimum check for usage of that address, and consider duration carefully. IP addresses should rarely, if ever, be blocked indefinitely. Collateral damage When an IP range is blocked, other users who also use that range may be unintentionally affected. If you propose to block a significant IP range, especially for a significant time, consider asking a user with checkuser access to check for collateral damage on that range—that is, for the presence of other users who may be unintentionally affected by the range block. They may be able to be given IP block exemption so they will not be affected. Duration of blocks The purpose of blocking is prevention, not punishment. The duration of blocks should thus be related to the likelihood of a user repeating inappropriate behavior. Longer blocks for repeated and high levels of disruption is to reduce administrative burden; it is under presumption that such users are likely to cause frequent disruption or harm in future. Administrators should consider: *the severity of the behavior; *whether the user has engaged in that behavior before. Blocks on shared or dynamic IP addresses are typically shorter than blocks on registered accounts or static IP addresses made in otherwise similar circumstances, to limit side-effects on other users sharing that IP address. While the duration of a block should vary with the circumstances, there are some broad standards: *incidents of disruptive behaviour typically result in 24 hours blocks, longer for successive violations; *accounts used primarily for disruption may be blocked indefinitely without warning; *protective blocks typically last as long as protection is necessary, often indefinitely. Indefinite blocks An indefinite block is a block that does not have a fixed duration. Indefinite blocks are usually applied when there is significant disruption or threats of disruption, or major breaches of policy. In such cases an open-ended block may be appropriate to prevent further problems until the matter can be resolved by discussion. If no administrator is willing to lift the block, the blocked user is effectively considered to have been banned by the community. In less extreme cases, however, the more usual desired outcome is a commitment to observe Wikipedia's policies and—if unblocked—to refrain from the problematic conduct in future. Setting block options There are several options available to modify the effect of blocks, which should be used in certain circumstances. * prevent account creation should typically be disabled when blocking accounts with inappropriate names (to allow the user to create an account with an appropriate name), though it should be enabled when blocking bad-faith names (for example, clear attacks on other users) or vandalism-only accounts. * block e-mail will disable the user from accessing Special:Emailuser for the duration of the block. This option should not be used by default when blocking an account, but rather it should only be used in cases of abuse of the "email this user" feature (still, in instances when an admin feels email abuse is extremely likely, they may use their discretion). When enabled, efforts should be taken to ensure that the user's talk page remains unprotected and that the user is aware of other avenues (such as the unblock-en-l mailing list) through which he can discuss the block. The most common types of blocks when blocking an IP are commonly known as a soft block (autoblock disabled, account creation not disabled, blocking only anonymous users enabled) which block anonymous users but allow editing by registered users when logged in (commonly used when blocking shared IP addresses); soft block with account creation disabled (same but account creation disabled) used in most cases where vandalism or disruption is occurring via registered accounts; and hard block, which disables all editing whether logged in or not, other than administrators and other IP-block exempt users – used when the level of vandalism or disruption via creation of "throwaway" accounts is such that editing from the IP is to be prevented other than after individual checking of requests. Open proxies are hard blocked upon detection.